The attribute release policy decides how attributes are selected and provided to a given application in the final
CAS response. Additionally, each policy has the ability to apply an optional filter to weed out their attributes based on their values.
The following settings are shared by all attribute release policies:
Boolean to define whether this policy should exclude the default global bundle of attributes for release.
authorizedToReleaseAuthenticationAttributes
Boolean to define whether this policy should exclude the authentication/protocol attributes for release. Authentication attributes are considered those that are not tied to a specific principal and define extra supplementary metadata about the authentication event itself, such as the commencement date.
principalIdAttribute
An attribute name of your own choosing that will be stuffed into the final bundle of attributes, carrying the CAS authenticated principal identifier. By default, the principal id is NOT released as an attribute.
Usage Warning!
Think VERY CAREFULLY before turning on
the above settings. Blindly authorizing an application to receive a proxy-granting ticket or the user credential
may produce an opportunity for security leaks and attacks. Make sure you actually need to enable those features and that
you understand the why. Avoid where and when you can, specially when it comes to sharing the user credential.
CAS makes a distinction between attributes that convey metadata about the authentication event versus
those that contain personally identifiable data for the authenticated principal.
Actuator Endpoints
The following endpoints are provided by CAS:
The following settings and properties are available from the CAS configuration catalog:
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
Define the password encoder type to use. Type may be specified as blank or NONE to disable password encoding. It may also refer to a fully-qualified class name that implements the Spring Security's PasswordEncoder interface if you wish you define your own encoder. The following types may be used:
NONE: No password encoding (i.e. plain-text) takes place.
DEFAULT: Use the DefaultPasswordEncoder of CAS. For message-digest algorithms via character-encoding and encoding-algorithm.
BCRYPT: Use the BCryptPasswordEncoder based on the strength provided and an optional secret.
SCRYPT: Use the SCryptPasswordEncoder.
PBKDF2: Use the Pbkdf2PasswordEncoder based on the strength provided and an optional secret.
STANDARD: Use the StandardPasswordEncoder based on the secret provided.
SSHA: Use the LdapShaPasswordEncoder supports Ldap SHA and SSHA (salted-SHA). The values are base-64 encoded and have the label SHA</code> or SSHA</code> prepended to the encoded hash.
GLIBC_CRYPT: Use the GlibcCryptPasswordEncoder based on the encoding-algorithm, strength provided and an optional secret.
org.example.MyEncoder: An implementation of PasswordEncoder of your own choosing.
file:///path/to/script.groovy: Path to a Groovy script charged with handling password encoding operations.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
cas.monitor.endpoints.jdbc.pool.max-size=18
Controls the maximum number of connections to keep in the pool, including both idle and in-use connections.
The default auto-commit behavior of connections in the pool. Determined whether queries such as update/insert should be immediately executed without waiting for an underlying transaction.
Hibernate feature to automatically validate and exports DDL to the schema. By default, creates and drops the schema automatically when a session is starts and ends. Setting the value to validate or none may be more desirable for production, but any of the following options can be used:
validate: Validate the schema, but make no changes to the database.
update: Update the schema.
create: Create the schema, destroying previous data.
create-drop: Drop the schema at the end of the session.
none: Do nothing.
Note that during a version migration where any schema has changed create-drop will result in the loss of all data as soon as CAS is started. For transient data like tickets this is probably not an issue, but in cases like the audit table important data could be lost. Using `update`, while safe for data, is confirmed to result in invalid database state. validate or none settings are likely the only safe options for production use. For more info, see this.
The database dialect is a configuration setting for platform independent software (JPA, Hibernate, etc) which allows such software to translate its generic SQL statements into vendor specific DDL, DML.
Any value greater than zero will be treated as a timeout for pool initialization. The calling thread will be blocked from continuing until a successful connection to the database, or until the timeout is reached. If the timeout is reached, then a PoolInitializationException will be thrown.
A value of zero will not prevent the pool from starting in the case that a connection cannot be obtained. However, upon start the pool will attempt to obtain a connection and validate that the connectionTestQuery and connectionInitSql are valid. If those validations fail, an exception will be thrown. If a connection cannot be obtained, the validation is skipped and the the pool will start and continue to try to obtain connections in the background. This can mean that callers to DataSource#getConnection() may encounter exceptions.
A value less than zero will not bypass any connection attempt and validation during startup, and therefore the pool will start immediately. The pool will continue to try to obtain connections in the background. This can mean that callers to DataSource#getConnection() may encounter exceptions.
Note that if this timeout value is greater than or equal to zero (0), and therefore an initial connection validation is performed, this timeout does not override the connectionTimeout or validationTimeout; they will be honored before this timeout is applied. The default value is one millisecond.
This property determines whether data source isolates internal pool queries, such as the connection alive test, in their own transaction.
Since these are typically read-only queries, it is rarely necessary to encapsulate them in their own transaction. This property only applies if #autocommit is disabled.
Strength or number of iterations to use for password hashing. Usually relevant when dealing with PBKDF2 or BCRYPT encoders. Used by GLIBC_CRYPT encoders as well.
Control global properties that are relevant to Hibernate,
when CAS attempts to employ and utilize database resources,
connections and queries.
If you need to design your own password encoding scheme where the type is specified as a fully
qualified Java class name, the structure of the class would be similar to the following:
If you need to design your own password encoding scheme where the type is
specified as a path to a Groovy script, the structure of the script would be similar to the following:
importjava.util.*byte[]run(finalObject...args){defrawPassword=args[0]defgeneratedSalt=args[1]deflogger=args[2]defcasApplicationContext=args[3]logger.debug("Encoding password...")return...}Booleanmatches(finalObject...args){defrawPassword=args[0]defencodedPassword=args[1]deflogger=args[2]defcasApplicationContext=args[3]logger.debug("Does match or not ?");return...
The following settings and properties are available from the CAS configuration catalog:
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
cas.monitor.endpoints.ldap.base-dn=
Base DN to use. There may be scenarios where different parts of a single LDAP tree could be considered as base-dns. Rather than duplicating the LDAP configuration block for each individual base-dn, each entry can be specified and joined together using a special delimiter character. The user DN is retrieved using the combination of all base-dn and DN resolvers in the order defined. DN resolution should fail if multiple DNs are found. Otherwise the first DN found is returned. Usual syntax is: subtreeA,dc=example,dc=net|subtreeC,dc=example,dc=net.
The bind DN to use when connecting to LDAP. LDAP connection configuration injected into the LDAP connection pool can be initialized with the following parameters:
bindDn/bindCredential provided - Use the provided credentials to bind when initializing connections.
bindDn/bindCredential set to * - Use a fast-bind strategy to initialize the pool.
bindDn/bindCredential set to blank - Skip connection initializing; perform operations anonymously.
SASL mechanism provided - Use the given SASL mechanism to bind when initializing connections.
User filter to use for searching. Syntax is cn=user or cn=0. You may also provide an external groovy script in the syntax of file:/path/to/GroovyScript.groovy to fully build the final filter template dynamically.
AUTHENTICATED - Manager bind/search type of authentication. If principalAttributePassword</code> is empty then a user simple bind is done to validate credentials. Otherwise the given attribute is compared with the given principalAttributePassword using the SHA encrypted value of it.
ANONYMOUS: Similar semantics as AUTHENTICATED except no bindDn and bindCredential may be specified to initialize the connection. If principalAttributePassword is empty then a user simple bind is done to validate credentials. Otherwise the given attribute is compared with the given principalAttributePassword using the SHA encrypted value of it.
DIRECT: Direct Bind - Compute user DN from format string and perform simple bind. This is relevant when no search is required to compute the DN needed for a bind operation. Use cases for this type are: 1) All users are under a single branch in the directory, e.g. ou=Users,dc=example,dc=org. 2) The username provided on the CAS login form is part of the DN, e.g. uid=%s,ou=Users,dc=example,dc=org.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
Attribute expected to be found on the entry resulting from the group search whose value is going to be used to construct roles. The final value is always prefixed with #groupPrefix. This is useful in scenarios where you wish to grant access to a resource to all users who a member of a given group.
Attribute expected to be found on the entry whose value is going to be used to construct roles. The final value is always prefixed with #rolePrefix. This is useful in scenarios where you wish to grant access to a resource to all users who carry a special attribute.
The type of search entry handler to choose.
Available values are as follows:
ACTIVE_DIRECTORY: Process the entry results fetched from active directory and
check for account status controls for disabled/expired accounts, etc.
OBJECT_GUID: Object guid search entry handler.
Handles the objectGUID attribute fetching and conversion.
OBJECT_SID: Object sid search entry handler.
Handles the objectSid attribute fetching and conversion.
CASE_CHANGE: Case change search entry handler.
Provides the ability to modify the case of search entry DNs, attribute names, and attribute values.
DN_ATTRIBUTE_ENTRY: DN attribute entry handler.
Adds the entry DN as an attribute to the result set. Provides
a client side implementation of RFC 5020.
MERGE: Merge search entry handler.
Merges the values of one or more attributes into a single attribute.
PRIMARY_GROUP: Primary group search handler.
Constructs the primary group SID and then searches for
that group and puts it's DN in the memberOf attribute of the original search entry.
RANGE_ENTRY: Range entry search handler.
Rewrites attributes returned from Active Directory to
include all values by performing additional searches.
RECURSIVE_ENTRY: Recursive entry search handler.
This recursively searches based on a supplied
attribute and merges those results into the original entry.
Determine the LDAP validator type. The following LDAP validators can be used to test connection health status:
search: Validates a connection is healthy by performing a search operation. Validation is considered successful if the search result size is greater than zero.
none: No validation takes place.
compare: Validates a connection is healthy by performing a compare operation.
The length of time the pool will block. By default the pool will block indefinitely and there is no guarantee that waiting threads will be serviced in the order in which they made their request. This option should be used with a blocking connection pool when you need to control the exact number of connections that can be created
This settings supports the
java.time.Duration syntax [?].
Removes connections from the pool based on how long they have been idle in the available queue. Prunes connections that have been idle for more than the indicated amount.
This settings supports the
java.time.Duration syntax [?].
Request that the server return results in batches of a specific size. See RFC 2696. This control is often used to work around server result size limits. A negative/zero value disables paged requests.
You may receive unexpected LDAP failures, when CAS is configured to authenticate using DIRECT or AUTHENTICATED types and LDAP is locked down to not allow anonymous binds/searches. Every second attempt with a given LDAP connection from the pool would fail if it was on the same connection as a failed login attempt, and the regular connection validator would similarly fail. When a connection is returned back to a pool, it still may contain the principal and credentials from the previous attempt. Before the next bind attempt using that connection, the validator tries to validate the connection again but fails because it’s no longer trying with the configured bind credentials but with whatever user DN was used in the previous step. Given the validation failure, the connection is closed and CAS would deny access by default. Passivators attempt to reconnect to LDAP with the configured bind credentials, effectively resetting the connection to what it should be after each bind request. Furthermore if you are seeing errors in the logs that resemble a 'Operation exception encountered, reopening connection' type of message, this usually is an indication that the connection pool’s validation timeout established and created by CAS is greater than the timeout configured in the LDAP server, or more likely, in the load balancer in front of the LDAP servers. You can adjust the LDAP server session’s timeout for connections, or you can teach CAS to use a validity period that is equal or less than the LDAP server session’s timeout. Accepted values are:
NONE: No passivation takes place.
BIND: The default behavior which passivates a connection by performing a bind operation on it. This option requires the availability of bind credentials when establishing connections to LDAP.
If principalAttributePassword is empty then a user simple bind is done to validate credentials otherwise the given attribute is compared with the given principalAttributePassword using the SHA encrypted value of it.
For the anonymous authentication type, if principalAttributePassword is empty then a user simple bind is done to validate credentials otherwise the given attribute is compared with the given principalAttributePassword using the SHA encrypted value of it.
Trust Manager options. Trust managers are responsible for managing the trust material that is used when making LDAP trust decisions, and for deciding whether credentials presented by a peer should be accepted. Accepted values are: *
DEFAULT: Enable and force the default JVM trust managers.
Path to the keystore used to determine which certificates or certificate authorities should be trusted. Used when connecting to an LDAP server via LDAPS or startTLS connection. If left blank, the default truststore for the Java runtime is used.
The type of trust keystore that determines which certificates or certificate authorities are trusted. Types depend on underlying java platform, typically PKCS12 or JKS. If left blank, defaults to the default keystore type indicated by the underlying Java platform.
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
The login context name should coincide with a given index in the login config specified. This name is used as the index to the configuration specified in the login config property.
CAS, being a Spring-Boot application at heart, includes a number of endpoints to help you monitor and manage the server when it’s pushed to production. You can choose to manage and monitor the deployment using HTTP endpoints, referred to as actuators.
In essence, actuator endpoints bring production-ready features to CAS. Monitoring a running CAS instance, gathering metrics, understanding traffic or the state of our database becomes trivial with such endpoints. The main benefit of these endpoints is that we can get production grade tools without having to actually implement these features ourselves. Actuators are mainly used to expose operational information about the running application – health, metrics, etc. These are HTTP endpoints or JMX beans to enable us to interact with it.
Actuator endpoints are presented by CAS in two categories:
Those that are owned and defined by the CAS project.
Those that are owned and defined by third-party projects, frameworks and libraries such as Spring Boot.
Exposed Endpoints
Note that by default the only endpoints exposed over the web
are info, status, health and configurationMetadata.
Other endpoints need to be explicitly enabled and then
exposed over the web in CAS settings in order to allow access.
This endpoint, releaseAttributes can be turned
on by including the following dependency in the WAR overlay:
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
cas.monitor.endpoints.form-login-enabled=false
Control whether access to endpoints can be controlled via form-based login over the web via a special admin login endpoint.
Whether unique runtime object names should be ensured.
Deprecation status is ERROR
with a replacement setting: spring.jmx.unique-names.
management.endpoints.migrate-legacy-ids=false
Whether to transparently migrate legacy endpoint IDs.
management.endpoints.web.base-path=/actuator
Base path for Web endpoints. Relative to the servlet context path (server.servlet.context-path) or WebFlux base path (spring.webflux.base-path) when the management server is sharing the main server port. Relative to the management server base path (management.server.base-path) when a separate management server port (management.server.port) is configured.
Comma-separated list of origin patterns to allow. Unlike allowed origins which only supports '*', origin patterns are more flexible (for example 'https://*.example.com') and can be used when credentials are allowed. When no allowed origin patterns or allowed origins are set, CORS support is disabled.
Comma-separated list of origins to allow. '*' allows all origins. When credentials are allowed, '*' cannot be used and origin patterns should be configured instead. When no allowed origins or allowed origin patterns are set, CORS support is disabled.
For basic authentication, the default username is casuser. The password may be automatically generated at startup and displayed in CAS logs if it is left undefined in CAS settings. Additional sources may also be defined that would authenticate the request via JAAS, LDAP, JDBC, etc.
Once endpoints are enabled and exposed, the security of all provided endpoints
is handled
by the Spring Security
project.
Protection and access to each endpoint
is controlled via CAS settings individually such that you may
decide a specific security level and method of authentication for each endpoint
independently.
If CAS is configured to NOT enforce endpoint security
rules, then
all endpoints are considered sensitive and require authentication, typically
handled
via basic authentication with master credentials defined in CAS settings.
If CAS is configured to enforce endpoint security rules, then each
endpoint may be tagged with a specific security rule allowing access via
authorized IP addresses,
basic credentials, roles and attributes, etc.
Defaults
There is a special endpoint named defaults which serves as a shortcut that
controls the security of all endpoints, if left undefined in CAS settings.
To enable additional logging, configure the log4j configuration file to add the
following levels:
CAS, being a Spring-Boot application at heart, includes a number of endpoints to help you monitor and manage the server when it’s pushed to production. You can choose to manage and monitor the deployment using HTTP endpoints, referred to as actuators.
In essence, actuator endpoints bring production-ready features to CAS. Monitoring a running CAS instance, gathering metrics, understanding traffic or the state of our database becomes trivial with such endpoints. The main benefit of these endpoints is that we can get production grade tools without having to actually implement these features ourselves. Actuators are mainly used to expose operational information about the running application – health, metrics, etc. These are HTTP endpoints or JMX beans to enable us to interact with it.
Actuator endpoints are presented by CAS in two categories:
Those that are owned and defined by the CAS project.
Those that are owned and defined by third-party projects, frameworks and libraries such as Spring Boot.
Exposed Endpoints
Note that by default the only endpoints exposed over the web
are info, status, health and configurationMetadata.
Other endpoints need to be explicitly enabled and then
exposed over the web in CAS settings in order to allow access.
This endpoint, releaseAttributes can be turned
on by including the following dependency in the WAR overlay:
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
cas.monitor.endpoints.form-login-enabled=false
Control whether access to endpoints can be controlled via form-based login over the web via a special admin login endpoint.
Whether unique runtime object names should be ensured.
Deprecation status is ERROR
with a replacement setting: spring.jmx.unique-names.
management.endpoints.migrate-legacy-ids=false
Whether to transparently migrate legacy endpoint IDs.
management.endpoints.web.base-path=/actuator
Base path for Web endpoints. Relative to the servlet context path (server.servlet.context-path) or WebFlux base path (spring.webflux.base-path) when the management server is sharing the main server port. Relative to the management server base path (management.server.base-path) when a separate management server port (management.server.port) is configured.
Comma-separated list of origin patterns to allow. Unlike allowed origins which only supports '*', origin patterns are more flexible (for example 'https://*.example.com') and can be used when credentials are allowed. When no allowed origin patterns or allowed origins are set, CORS support is disabled.
Comma-separated list of origins to allow. '*' allows all origins. When credentials are allowed, '*' cannot be used and origin patterns should be configured instead. When no allowed origins or allowed origin patterns are set, CORS support is disabled.
For basic authentication, the default username is casuser. The password may be automatically generated at startup and displayed in CAS logs if it is left undefined in CAS settings. Additional sources may also be defined that would authenticate the request via JAAS, LDAP, JDBC, etc.
Once endpoints are enabled and exposed, the security of all provided endpoints
is handled
by the Spring Security
project.
Protection and access to each endpoint
is controlled via CAS settings individually such that you may
decide a specific security level and method of authentication for each endpoint
independently.
If CAS is configured to NOT enforce endpoint security
rules, then
all endpoints are considered sensitive and require authentication, typically
handled
via basic authentication with master credentials defined in CAS settings.
If CAS is configured to enforce endpoint security rules, then each
endpoint may be tagged with a specific security rule allowing access via
authorized IP addresses,
basic credentials, roles and attributes, etc.
Defaults
There is a special endpoint named defaults which serves as a shortcut that
controls the security of all endpoints, if left undefined in CAS settings.
To enable additional logging, configure the log4j configuration file to add the
following levels:
During the authentication process, a number of attributes get captured and collected by CAS
to describe metadata and additional properties about the nature of the authentication event itself.
These typically include attributes that are documented and classified by the underlying protocol
or attributes that are specific to CAS which may describe the type of credentials used, successfully-executed
authentication handlers, date/time of the authentication, etc.
Releasing authentication attributes to service providers and applications can be
controlled to some extent.
The following settings and properties are available from the CAS configuration catalog:
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Protocol/authentication attributes may also be released conditionally on a per-service basis.
Principal Attributes
Principal attributes typically convey personally identifiable data about the authenticated user,
such as address, last name, etc. Release policies are available in CAS and documented below
to explicitly control the collection of attributes that may be authorized for release to a given application.
Remember
Depending on the protocol used and the type/class of service (i.e. relying party) registered with CAS,
additional release policies may become available that allow more fine-tuned control over attribute release, catering better to the needs of the particular
authentication protocol at hand. Remember to verify attribute release capabilities of CAS by visiting and studies the appropriate documentation for each protocol.
Default
CAS provides the ability to release a bundle of principal attributes to all services by default. This bundle
is not defined on a per-service basis and is always combined with attributes produced by the specific
release policy of the service, such that for instance, you can devise rules to always release givenName
and cn to every application, and additionally allow other specific principal attributes for
only some applications per their attribute release policy.
The following settings and properties are available from the CAS configuration catalog:
The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.
The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.
CAS provides the ability to release a bundle of principal attributes to all services by default. This bundle is not defined on a per-service basis and is always combined with attributes produced by the specific release policy of the service, such that for instance, you can devise rules to always release givenName and cn to every application, and additionally allow other specific principal attributes for only some applications per their attribute release policy.
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc. When possible, properties should be stored in
lower-case kebab format, such as cas.property-name=value.S ettings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.
Return All
Return all resolved principal attributes to the service,
and optionally exclude attributes from the final collection.
Attributes authorized and allowed for release by this policy may not necessarily be available
as resolved principal attributes and can be resolved on the fly dynamically
using the attribute definition store.
Return Encrypted
Encrypt and encode all all allowed attributes in base-64 using the assigned registered service public key.
The keys can be generated via the following commands:
1
2
3
openssl genrsa -out private.key 1024
openssl rsa -pubout-in private.key -out public.key -inform PEM -outform DER
openssl pkcs8 -topk8-inform PER -outform DER -nocrypt-in private.key -out private.p8
Attributes authorized and allowed for release by this policy may not necessarily be available
as resolved principal attributes and can be resolved on the fly dynamically
using the attribute definition store.
REST
Only return the principal attributes that are explicitly allowed by contacting a REST endpoint. Endpoints must be designed to
accept/process application/json. The expected response status code is 200 where the body of
the response includes a Map of attributes linked to their values.
The following parameters are passed to the endpoint:
Parameter
Description
principal
The object representing the authenticated principal.
service
The object representing the corresponding service definition in the registry.
The body of the submitted request may also include a Map of currently resolved attributes.
Return Mapped
Similar to above, this policy will return a collection of allowed principal attributes for the
service, but also allows those principal attributes to be mapped and “renamed” at the more granular service level.
For example, the following configuration will recognize the resolved
attributes eduPersonAffiliation and groupMembership and will then
release affiliation and group to the web application configured.
Attributes authorized and allowed for release by this policy may not necessarily be available
as resolved principal attributes and can be resolved on the fly dynamically
using the attribute definition store.
Return MultiMapped
The same policy may allow attribute definitions to be renamed and remapped to multiple attribute names,
with duplicate attributes values mapped to different names.
For example, the following configuration will recognize the resolved attribute eduPersonAffiliation and will then
release affiliation and personAffiliation whose values stem from the original eduPersonAffiliation attribute
while groupMembership is released as group. In other words, the eduPersonAffiliation attribute is
released twice under two different names each sharing the same value.
Attributes authorized and allowed for release by this policy may not necessarily be available
as resolved principal attributes and can be resolved on the fly dynamically
using the attribute definition store.
Inline Groovy Attributes
Principal attributes that are mapped may produce their values from an inline groovy script. As an example, if you currently
have resolved a uid attribute with a value of piper, you could then consider the following:
1
2
3
4
5
6
7
8
9
10
11
12
13
{"@class":"org.apereo.cas.services.RegexRegisteredService","serviceId":"sample","name":"sample","id":300,"attributeReleasePolicy":{"@class":"org.apereo.cas.services.ReturnMappedAttributeReleasePolicy","allowedAttributes":{"@class":"java.util.TreeMap","uid":"groovy { return attributes['uid'].get(0) + ' is great' }"}}}
In the above snippet, the value of the uid attribute name is mapped to the result of the inline groovy script.
Inline scripts always begin with the syntax groovy {...} and are passed the current collection of resolved
attributes as an attributes binding variable. The result of the script can be a single/collection of value(s).
The above configuration will produce a uid attribute for the application whose value is a concatenation of
the original value of uid plus the words “ is great”, so the final result would be “piper is great”.
File-based Groovy Attributes
Identical to inline groovy attribute definitions, except the groovy script can also be externalized to a .groovy file:
Let an external Groovy script decide how principal attributes should be released. The configuration of this
component qualifies to use the Spring Expression Language syntax.
importjava.util.*defMap<String,List<Object>>run(finalObject...args){defcurrentAttributes=args[0]deflogger=args[1]defprincipal=args[2]defservice=args[3]logger.debug("Current attributes received are {}",currentAttributes)return[username:["something"],likes:["cheese","food"],id:[1234,2,3,4,5],another:"attribute"]}
The following parameters are passed to the script:
Parameter
Description
currentAttributes
Map of attributes currently resolved and available for release.
logger
The object responsible for issuing log messages such as logger.info(...).
principal
The object representing the authenticated principal.
service
The object representing the corresponding service definition in the registry.
Script Engines
Usage
This feature is deprecated and is scheduled to be removed in the future.
Use alternative script engine implementations and other programming languages to configure attribute release policies. This approach
takes advantage of scripting functionality built into the Java platform via additional libraries and drivers. While Groovy should be
natively supported by CAS, the following module is required in the overlay to include support for additional languages
such as Python, etc.
The configuration of this component qualifies to use
the Spring Expression Language syntax. The scripts
need to design a run function that receives a list of parameters. The collection of current attributes in process
as well as a logger object are passed to this function. The result must produce a map whose keys are attributes names
and whose values are a list of attribute values.
As an example, the script itself may be designed in Groovy as:
1
2
3
4
5
6
7
8
9
importjava.util.*defMap<String,List<Object>>run(finalObject...args){defcurrentAttributes=args[0]deflogger=args[1]logger.debug("Current attributes received are {}",currentAttributes)return[username:["something"],likes:["cheese","food"],id:[1234,2,3,4,5],another:"attribute"]}
Here’s the same script written in Python:
1
2
3
4
5
defrun(*Params):Attributes=Params[0]Logger=Params[1]# Calculate attributes and return a new dictionary of attributes...
return...
You are also allowed to stuff inlined groovy scripts into the scriptFile attribute. The script
has access to the collection of resolved attributes as well as a logger object.
Attribute release policies can be assigned a principalAttributesRepository to consult attribute sources
defined and controlled by Person Directory attribute repositories
to fetch, resolve, cache and release attributes. To learn more about this topic, please see this guide.
Chaining Policies
Attribute release policies can be chained together to process multiple rules.
The order of policy invocation is the same as the definition order defined for the service itself.
Attributes are merged such that attributes from the source always replace principal attributes.
add
Attributes are merged such that attributes from the source that don’t already exist for the principal are produced.
multivalued
Attributes with the same name are merged into multi-valued attributes.
Ordering Policies
Note that each policy in the chain can be assigned a numeric order that would determine its position in the chain before execution. This
order may be important if you have attribute release policies that should calculate a value dynamically first before passing it onto
the next policy in the chain.
For example, the policy chain below allows CAS to generate an attribute first using the GeneratesFancyAttributeReleasePolicy policy
where the attribute is next passed onto the next policy in the chain, that is ReleaseFancyAttributeReleasePolicy, to decide
whether or not the attribute should be released. Note the configuration of policy order determines the execution sequence.
While each policy defines what principal attributes may be allowed for a given service,
there are optional attribute filters that can be set per policy to further weed out attributes based on their values.
